Collection of Internet/Collection of Internet.iso/infosrvr/dev/www_talk.930/[e-mail] _Tue Jan 12 12:00:56 1993.msg

Internet Message Format | 1994-01-24 | 4KB

Return-Path: <[e-mail]>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
    id AA21272; Tue, 12 Jan 93 12:00:56 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
    id AA03266; Tue, 12 Jan 1993 12:16:04 +0100
Received: from danton.cc.rl.ac.uk by directory.rl.ac.uk with SMTP (PP)
          id <[e-mail]>; Tue, 12 Jan 1993 11:01:08 +0000
Date: Mon, 11 Jan 1993 16:27:37 +0000 (GMT)
From: Kevin Hoadley <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Subject: RE: Re HTTP2: caching and copyright
To: Dave_Raggett <[e-mail]>
Cc: [e-mail]
In-Reply-To: Dave_Raggett's message of Mon, 11 Jan 93 15:42:41 GMT: <[e-mail]>
Message-Id: <Ximap.726837388.7590.khoadley@danton>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

>>> Note that servers shouln't cache documents with restricted readership since
>>> each server don't know the restrictions to apply. This requires a further
>>> header to identify such documents as being unsuitable for general caching:
>>>
>>>     Distribution: restricted | unrestricted

     There are a number of reasons why it might not be sensible
   to cache a document, eg in my local server I have a page
   entitled "Current state of the network". This is a smart doc,
   refreshed everytime it is accessed. Caching this is just plain
   silly. Thus a general mechanism (separate from access restrictions)
   is needed to prevent caching where it is unsuitable.
     Given that a general mechanism is also needed for cache timeouts,
   it seems sensilble to amalgamate the two, ie documents that should
   not be cached simply have their cache timeouts (TTL's) set to zero.
     Note that within the PROTOCOL, cache timing information should
   not be embedded within documents, for the simple reason that in the
   future such information will be needed for non-text bodyparts,
   ie my network status page might become a graphic, but it still
   should not be cached. Note that this does not stop any server
   IMPLEMENTATION from reading caching info embedded into in HTML,
   merely that the protocol (the bits on the wire) should be able to
   seperate the two.

>It would be nice in some circumstances to define the readership groups for
>situations where a server could apply group membership information to
>restrict readership.
...
>This says that the document can be given to anyone in psl and anyone in the
>kbpd subgroup of incl. You can make these names correspond to your
>organisation. The maintenance of these readership groups is outside
>the scope of the HTTP2 protocol.
>Local servers shouldn't cache documents including this
>header unless they "understand" the specified readership groups
>and can apply the same membership tests.

       How does a server know if it "understands" readership groups ?
     How do I know if my Dave Raggett is the same as your Dave Raggett ?
     This information cannot be passed between servers; we would need
     a global naming scheme - X.500 distinguished names won't do
     as X.500 is not commonly enough used, e-mail addresses probably
     aren't good enough (at a quick count I can be reached through
     about 20 addresses at 4 institutes in 2 countries, does this
     mean that my membership or otherwise of a readership group
     depends on where I am logged on ?). We would also need a global
     authentication scheme ...
       This comes back to the idea that the only documents that should
     be cached are those whose read access is totally unlimited. Any
     other form of read access (ie, billed access to private data,
     logged access, restricted access) should require talking to
     the original server, not to some cached copy.

Kevin Hoadley